I'm normally running in View🞃 Split… ✓Code-Live
I've used MS PowerToys Keyboard Manager feature to remap the F1-F12 keys to various Unicode characters (and one string) frequently employed.
Some of these are Unicode BMP characters (U+0000 to U+FFFF) range, such as: ⇩ U+21E9 DOWNWARDS WHITE ARROW These work everywhere I've used them.
About half of them, however, are from the Unicode SMP range (U+10000 and up), such as: :magnifying_glass_tilted_right: U+1F50E RIGHT-POINTING MAGNIFYING GLASS These work in all other apps, but can crash DW, when: ☐ entered via the remapped Fₙ keypress ☐ but only in the DW Code View window.
When typed into Code View, DW freezes, thinks about it for several seconds, and then crashes, throwing a Sorry, an error occurred dialog. I can repeat this reliably via New HTML document, where merely trying to type: ‹p›🔎‹/p› in the ‹Body› content.
The Error report details curiously includes: ‹crash exception="EXCEPTION_UNKNOWN" exceptionCode="0xe06d7363" instruction="0x00007FF95D1E782A"›
SMP otherwise works in DW. There is no crash when: ◊ typed into DW Live View window via that same Fₙ key🤔 ◊ pasted into Code View from elsewhere (including from the Live View window) ◊ entered as Entity markup 🔎 or 🔎
I have no solid guesses as to what's happening. Is PowerToys sending UTF-16, UTF-32 or even UCS-2, into an app expecting ‹meta charset="utf-8"› ?
So I'm not sure this is Adobe's problem. But if you encounter it, the work-arounds are above. And if you can't replicate it, that would be interesting. In actual working documents, a fair amount of work can be lost, not present in any recovery file DW has created. So save early & often.
Tech Notes: Windows 11 Pro 24H2 26100.7462 Dreamweaver 21.7 Angle brackets above are ‹ (&lsaquo) and › (›) to prevent re-interpretation by the site engine (as happened with some of the Unicode above—with any luck, the new forum engine won't be as destructive).
... View more